home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 91mar / area.security.91mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  8.0 KB  |  207 lines
  1.  
  2.  
  3. Security Area
  4.  
  5. Director(s):
  6.  
  7.    o Steve Crocker:  crocker@tis.com
  8.  
  9. Area Summary reported by Steve Crocker/TIS
  10.  
  11. The Security Area within the IETF is responsible for development of
  12. security oriented protocols, security review of RFCs, development of
  13. candidate policies, and review of operational security on the Internet.
  14.  
  15. This report has two parts.  The first section covers highlights from the
  16. meeting.  The second section covers the organization and operation of
  17. the Security Area.
  18.  
  19. HIGHLIGHTS
  20.  
  21. Security Policy and Site Security Policy Handbook (SPWG and SSPHWG)
  22.  
  23. Both the Security Policy and Site Security Policy Handbook Working
  24. Groups prepared drafts of their documents.  The security policy document
  25. is a concise statement of principles for protection of information
  26. assets and computing resources in the Internet.  Because it's intended
  27. to act as a guide to others who will establish policies for their
  28. networks, hosts, products, etc., the IAB determined that this document
  29. will be called a Guidelines and will be issued as an informational RFC.
  30. The document is now available as an Internet Draft.
  31.  
  32. The Site Security Policy Handbook is an extensive document that is
  33. intended to serve as a basis for tailoring site-specific policies.  It
  34. covers numerous facets of security including configuration, operation
  35. and responses to incidents.
  36.  
  37. These efforts are the result of the hard work and persistence of the
  38. Security Policy and Site Security Policy Handbook Working Groups.  The
  39. members and particularly the Chairs of these groups deserve
  40. congratulations for the work they have done.
  41.  
  42. Common Authentication Technology (CAT)
  43.  
  44. John Linn and Jeff Schiller will co-Chair a new Working Group to explore
  45. and define a common authentication framework.  This work will embrace
  46. MIT's Kerberos and Digital's SPx authentication servers.  Digital also
  47.  
  48.                                    1
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. unveiled its General Security Services Application Program Interface
  56. (GSSAPI) which provides a common interface for SPx, Kerberos and any
  57. other authentication service that may be defined in the future.  This
  58. work is intended to provide a uniform method for applications to
  59. authenticate connections in client-server and peer-peer connections.
  60.  
  61. Privacy Enhanced Mail (PEM)
  62.  
  63. The Privacy and Security Research Group (PSRG) under the Internet
  64. Research Task Force (IRTF) has revised the specifications for privacy
  65. enhanced mail.  The specifications are being released as Internet Drafts
  66. and will be reviewed through the usual open process.  At this IETF
  67. meeting, Jim Bidzos, the President of RSA Data Securityi, Inc, presented
  68. the outline of the forthcoming organizational agreement.  (RSADSI holds
  69. the patent on the RSA public key technology and is licensing its use for
  70. privacy enhanced mail within the Internet.)  Additional open meetings
  71. will be scheduled in forthcoming IETF meetings.
  72.  
  73. IP Security Option (IPSO)
  74.  
  75. Some time ago a protocol was defined for adding U.S. DoD security labels
  76. at the IP level.  The protocol was never fully completed and sat in an
  77. incomplete state.  Last fall, the effort was resurrected by Vint Cerf,
  78. the IAB Chair.  Steve Kent has now completed the revisions to the
  79. document, and it is now available as an Internet Draft.  This document
  80. covers only the Basic Security Option and is applicable only to the U.S.
  81. DoD security labels.  Another document is expected later which will
  82. cover the Extended Security Option, and a separate effort is described
  83. next which is intended to cover labels outside of the U.S. DoD
  84. hierarchy.
  85.  
  86. Trusted Systems Interoperability Group (TSIG -- CIPSO and TNFS)
  87.  
  88. The Trusted Systems Interoperability Group is a consortium of computer
  89. systems vendors developing protocols for trusted systems.  Has asked the
  90. IETF and IAB for assistance in standardizing their protocols.  The
  91. operation and rules of the TSIG are quite similar to the IAB and IETF.
  92. Each of the TSIG's protocols is developed by a TSIG Working Group whose
  93. deliberations are open to all.  In order to facilitate the publication
  94. of protocols developed by the TSIG, the individual TSIG Working Groups
  95. will be chartered as IETF Working Groups.  Two groups have submitted
  96. charters, CIPSO and TNFS.
  97.  
  98. The CIPSO Working Group is developing a commercial IP security option.
  99. This is intended to make security labels available to the commercial,
  100. civilian U.S. government and non-U.S. government communities.  A draft
  101. document is essentially complete and will be made available as an
  102. Internet Draft.
  103.  
  104.                                    2
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. The TNFS Working Group is developing a trusted version of the NFS
  112. (Network File System) protocol.  This work is being coordinated with the
  113. distributed file systems Working Group in the Applications area.  This
  114. work also depends on clarification of the status of NFS as a base for
  115. building other protocols.
  116.  
  117. ORGANIZATION AND OPERATION
  118.  
  119. Much of the work of the Security Area is performed in coordination with
  120. Working Groups in other areas.  Indeed, one of the primary tasks is to
  121. provide security expertise to Working Groups in other IETF areas.
  122.  
  123. Starting with the December 1990 IETF meeting, we organized a Security
  124. Area Advisory Group (SAAG) to gather together the limited number of
  125. people knowledgeable about security in protocols and to provide a
  126. coordinated forum for discussion of security issues in Internet
  127. protocols.  We've also established a pattern of having the SAAG meet
  128. twice during the IETF meeting, once at the beginning and once at the end
  129. of week.  Although these are business meetings devoted principally to
  130. assignment of tasks and coordination of new work items, observers are
  131. welcome.
  132.  
  133. SAAG Operation
  134.  
  135. The main bulk of work for the SAAG consists of a set of formal work
  136. items.  These work items correspond to three types of activities.
  137.  
  138. Security relevant developments within Working Groups in areas other than
  139. security.
  140.  
  141. Assistance to the Telnet Working Group on authentication and encryption
  142. is a typical example.  For items of this type, a SAAG member is assigned
  143. and supports the Working Groups.
  144.  
  145. Working groups within the Security Area.
  146.  
  147. The development of SNMP security is an example.  In many cases, even
  148. though a Working Group is in the Security Area, there are close ties to
  149. another area.  SNMP security is obviously tied closely to the Management
  150. area.  In several instances, it's a matter of choice whether a Working
  151. Group is in the Security Area or in another area.  These decisions are
  152. made on a case by case basis by mutual agreement of the respective Area
  153. Directors.  In these cases the work is usally coordinated closely with
  154. the relevant Area Director.
  155.  
  156. Preliminary inquiries
  157.  
  158.                                    3
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. These are topics which do not merit the creation of a formal Working
  166. Group but which do need some level of attention.  These are assigned to
  167. a SAAG member and followed for one or SAAG meeting.
  168.  
  169. In addition to the items formally being worked on by the SAAG, there are
  170. other discussions that take place but do not lead to the creation of a
  171. formal work item.  No follow up actions are scheduled for these.
  172.  
  173. The following table shows the work items and other discussions arranged
  174. by status (SAAG, Security Area, Other Area, Prelim) and by which area
  175. they interact with.  Minutes of the meetings of many of these groups are
  176. included in these proceedings.
  177.  
  178.                        SAAG            Security Area   Other Areas    Prelim
  179.  
  180. Security                export          spwg
  181.                        iabcc
  182.  
  183. Management                             snmpsec
  184.  
  185. User Services                          ssphwg
  186.  
  187. Routing                                                rreq
  188.  
  189. Applications            passwd          cat             telnet          email
  190.                        privdb          pem(2)          npp             nntp
  191.                        chronos                        tnfs(1)
  192.  
  193. Internet Services                      ipso                           iplpdn
  194.                                        cipso(1)
  195.  
  196. OSI                                                   ds
  197.  
  198. Operations
  199.  
  200.  
  201. (1) This is a TSIG WG
  202. (2) PEM is being developed by the PSRG
  203.  
  204.  
  205.  
  206.                                    4
  207.